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A  decision  was  made  in  mid-September  to  delay  shipment 

of  the  third  PSP  terminal,  which  was  scheduled  for  delivery  to 

Tanum,  Sweeden,  until  after  the  NTC  demonstration  in  late 

November.  Effort  was  therefore  focused  on  resolving  the  SIMP/PSP 

incompatabilities  in  the  terminals  installed  at  Etam  and  Goonhilly. 

v  ... 

The  major  effort  under  the  contract  during  this  reporting 

period  was  devoted  to  preparations  for  a  live  demonstration  of  the 
SATNET  technology,  which  is  scheduled  for  November  1979.  This 
demonstration  will  be  part  of  a  session  at  the  National  Teleconununica 
tions  Conference  (NTC)«  which  will  be  held  in  Washington,  D.C.  on 
27-29  November The  demonstration  will  include  packet  speech 
and  facsimile  transmission  between  the  conference  site  and 
University  College  London  (UCL).  COMSAT  is  presently  coordinating 
the  necessary  hardware  and  software  development  between  the  major 
participants .  -  /■■■ 

Activities  under  Task  3,  wideband  system  coordination/ 
integration,  havQ,  concentrated  on  additional  computer  simulations 
of  candidate  frequency  plans  for  the  EISN  carrier.  Meetings  were 
held  at  Western  Union  in  April,  and  again  in  July,  to  receive  the 
most  recent  planning  information  for  the  EISN  communication  link. 

This  information  was  incorporated  into  the  simulation  model  and 
additional  simulation  experiments  were  performed. 


2.  ACTIVITIES  UNDER  TASK  1:  TRANSITION  OF  SATNET 
TO  OPERATIONAL  STATUS 


2.1  INTRODUCTION 

During  the  reporting  period,  two  activities  have  been 
persued  relative  to  the  transition  of  SATNET  to  operational 
status.  In  July,  the  decision  was  made  to  request  a  nine  month 
extension  in  the  experimental  status  of  SATNET.  This  status  was 
due  to  expire  in  September  1979,  but  with  a  nine  month  extension, 
the  experimental  status  would  be  extended  until  June  1980.  The 
request  for  extension  was  submitted  in  August  1979. 

A  second  activity  under  this  task  was  continued 
monitoring  of  the  SATNET  data  which  is  received  each  day  from 
BB&N.  A  summary  of  these  data  for  August  and  September  is  given 
in  the  remainder  of  this  section. 


2.2  SATNET  PERFORMANCE  DATA 

Since  January  1979,  COMSAT  has  been  compiling  and 
summarizing  the  daily  data  on  missed  hello-packets  in  the  SATNET 
system  which  is  operating  between  Etam,  Goonhilly,  and  Tanum. 
These  data  have  provided  useful  information  about  the  general 
quality  of  the  nine  SATNET  links  and  their  variability  from  day 
to  day.  It  has  also  been  possible  to  deduce  link  bit-error 
probability  from  the  missed  hello-packet  data  and  to  compare 
these  results  to  the  performance  that  would  be  expected  in  the 
SPADE  transponder.  The  hello-packets  are  generated  continuously 

*Data  prior  to  August  is  included  in  Section  6  of  "Final  Report, 
COMSAT  Participation  in  ARPA  Packet  Satellite  Program  (PSP)," 
sponsored  by  DARPA,  ARPA  Order  No.  3287,  monitored  by  SAMSO/ 
YAPC  under  Contract  No.  F04701-C-0240,  October  1979,  by 
COMSAT  Laboratories,  Clarksburg,  Md.  20734. 


(approximately  66,000  per  day)  and  are  used  only  for  synchronization. 
As  such,  the  data  on  the  success  or  failure  of  hello-packet  recep¬ 
tion  gives  useful,  but  indirect,  evidence  of  the  degree  of  success 
experienced  by  users  who  are  transmitting  message  traffic  via  SATNET. 

In  April  1979,  an  additional  summary  of  the  SATNET  channel 
data  has  been  provided  each  day  by  BB&N .  The  new  data  applies 
directly  to  the  efficiency  of  SATNET  in  handling  the  message  traffic 
offered  to  it.  The  purpose  of  this  subsection  is  to  summarize 
the  new  data  and  to  propose  some  overall  "quality  measures,"  for 
SATNET  channel  performance. 


2.2.1  The  SATNET  Frame 


The  general  format  of  the  SATNET  frame  is  shown  in 
Figure  2-1.  This  frame  structure  has  been  in  effect  since  April  1979. 
The  data  subframes  are  27  virtual  slots  long.  During  a  day  there 
are  65,918  frames  each  of  which  contains  128  virtual  slots. 

84.4  percent  of  the  virtual  slots  are  available  for  sending  mes¬ 
sage  packets,  and  the  rest  are  used  for  the  hello-packets 
(3.1  percent)  and  the  control  packets  (12.5  percent).  With  the 
total  frame  divided  into  four  parts  as  shown  in  Figure  1,  there 
are  4  x  65,918  =  263,672  PODA  (priority-oriented  demand  assignment) 
frames  in  which  data  can  be  sent. 


2.2.2  Proposed  Measures  for  SATNET  Performance 

A  simple  model  can  be  proposed  to  subdivide  the  total 
time  in  one  day  according  to  the  following  events: 
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Ox  =  the  number  of  PODA  Frames  that  are  unavailable  for 

transmission  due  to  SIMP  "outages."  The  SIMP  outages 
fall  into  three  categories;  mi  =  minutes  SIMP  is  cross 
patched,  m2  =  minutes  SIMP  is  in  "loader/dumper,"  m3  = 
minutes  SIMP  is  not  reporting.  Using  the  conversion  f 
=  PODA  Frames/minute  =  263,672/1440  =  183.1,  outage  Oi 
can  be  obtained  as  Ox  =  f(mi  +  m2  +  m3 )  PODA  Frames. 

02  -  The  second  form  of  outage  occurs  when  the  SIMP  is  operating 
and  accepting  traffic  but  the  SATNET  network  is  out  of 
synchronization.  These  outages  can  be  due  to  several 
causes  i.e. , 

(a)  hello  frames  out  of  sync, 

(b)  SIMP  is  out  of  datagram  reservation  sync, 

(c)  SIMP  is  attempting  datagram  initial  acquisition, 
or 

(d)  SIMP  is  out  of  stream  sync 

Note  that  o2  should  indicate  the  number  of  PODA  frames  that  are 

unavailable  for  transmission  due  to  synchronization  problems. 

Presumably,  the  number  of  PODA  frames  in  datagram  reservation  sync, 

which  we  can  define  as  F-  can  be  obtained  as 

in 

Fin(k)  =  263,672  -  0,(k)  -  02(k)  (2.1) 

where ; 

F-  (k)  -  is  the  total  number  of  PODA  frames  in 
in' 

datagram  reservation  sync  at  transmitting 
station  k 

Oi(k)  -  number  of  elapsed  PODA  frames  during  SIMP 

outages  (available  from  the  data)  at  station 
k 

02(k)  -  number  of  PODA  frames  that  transmitting 

station  k  is  out  of  synchronization  (likewise 
available  from  the  summary  data) 


2-4 


It  is  proposed  that  the  first  efficiency  measure  used  is  simply 
the  ratio  of  F^/263,672  denoting  the  "potential"  PODA  frames 
which  are  available  for  sending  messages.  That  is, 

•  Fin(k)  •  •  • 

ni(k)  =  263,672  =  "Availability"  (2.2) 

This  first  efficiency  measure  asks  the  question,  "is  the  system 
able  to  handle  traffic  if  such  traffic  were  presented  to  it?" 

The  answer  to  this  question  can  be  "no"  for  two  reasons;  either 
the  SIMP  is  down,  or  the  station  is  out  of  synchronization.  The 
measure  m(M  is  an  important  first  measure  of  "availability"  and 
it  seems  to  be  readily  available  from  the  channel  summary  data. 

A  second  important  question  is,  how  much  traffic  was 
the  station  called  upon  to  transmit  during  the  periods  of  time 
when  it  was  "available"  to  transmit?  This  measures  the  loading 
presented  to  the  earth  station  and  this  number  also  seems  to  be 
readily  available  from  the  data  as  the  number  of  channel  data 
packets  transmitted,  which  will  be  denoted  as  Pt(k).  Unfortunately, 
the  number  of  virtual  slots  consumed  by  each  data  packet  are  not 
known  except  that  these  are  constrained  as; 

l  <  Virtual  Slots 
-  data  packet  - 


However,  the  average  virtual  slots  per  packet  is  not  known.  It 
is  proposed  for  now  that  the  loading  is  treated  in  terms  of  the 
parameter  V  ,  where  Vp  is  assumed  to  be  either  2  or  3  (See  Table 
2-1).  Until  more  accurate  information  is  available,  a  reasonable 
average  for  V  will  be  assumed  as  2.5;  which  will  be  denoted  as 


Table  2-1.  Assumed  Format  of  Data  Packets 


Symbol  Durations  in  Packet  Excluding  Data 


Symbols  Times  for  Carrier  Acquisition 
Symbol  Times  for  Clock  Recovery 
Unique  Word 

Syn-Syn-DLE-STX  Sequence 
Header  (17  16-bit  words) 

Data  (variable) 

DLE-ETX  Sequence 
Check  Sum 

Total  Length  of  packet  excluding 
data  and  guard  times 


60 

60 

16 

16 

136 

8 

12 

308  symbols  =  9.63  ms 


Guard  Times 


800  h  seconds  for  transmitter  "overhang"  time 
335  p  seconds  for  guard  time  (due  to  timing  inaccuracies) 
240  h  seconds  for  the  "staggering"  of  the  packet-start 
times  among  the  four  earth  stations 


Total 


1.375  ms 


Data  Bits  in  Packet  (maximum) 

#Virtual  Slots 
Assigned  to  a 
User 


Maximum  Number* 
of  Data  Bits  in 
Packet 


1 

2 

3 

4 

5 


0 

592 

1248 

1904 

2560 


Calculated  for  "N"  virtual  slots  as  [N  x  10.24  ms  -  9.63  ms  -  1.375  ms] 
x  64  rounding  to  lowest  number  of  16  bit  words. 


IT 
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c 
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Assuming  an  average  packet  length  of  Vp  virtual  slots, 
then  the  "loading"  measure  becomes 


p  (Data  packets]  #  V  V.S. 

_  rt^;  \ Transmitted  /  p  packet  (avg)^.  „ 


H2(k) 


F^_(k)  /frames\  2'7/V.S.  \ 
in  (Avail  J'  (iramej 


Loading"  (2.3) 


An  additional  measure  of  effectiveness  is  the  ratio  of 
total  packets  received  at  all  stations  to  total  packets  transmitted. 
This  ratio 


<k) 


ns  = 


k  =  1 


t-t 


=  "Success" 


(2.4) 


k  =  1 


(k) 

t 


applies  to  the  total  network. 

A  final  measure  that  reflects  total  network  loading  is: 


Ept(k)  •  V  Virtual  Slots 

p  used  for  Data 


n  4  = 


-  k  =  1 


263,672  x  27  Total  Virtual 
Slots/Day 


=  Composite  Loading 


The  efficiency  measures  rj 4  (Composite  loading),  03  (ratio  total 
packets  received  to  total  transmitted),  and  ni(k)  (availibility 
of  station  k;  k  =  1  for  ETAM,  =  2  for  Goonhilly,  =  3  for  Tanum) 
are  summarized  in  Table  2-2  for  certain  days  in  April  1979  when 
these  data  first  became  available. 

tit  has  been  found  in  reviewing  subsequent  summary  data  that  the 
measure  of  success  n 3  sometimes  gives  a  number  greater  than  one. 
When  this  number  exceeds  one,  more  packets  are  reported  received 
than  were  reported  as  transmitted  which  simply  means  that  some 
transmitted  packets  were  not  reported.  The  measure  rj3  thus  will 
not  be  very  useful  until  the  data  reporting  procedure  is  made 
more  reliable. 


Table  2-2.  Channel  Summary,  April  1979 


2.2.3 


Conclusions 


The  objective  here  has  been  to  propose  some  possible 
ways  to  utilize  the  new  channel  summary  data.  These  methods  use 
the  data  as  it  is  presently  available.  Useful  changes  in  format 
or  additional  data  would  be: 

a)  to  measure  and  record  average  data  packet  length  Vp 
rather  than  having  to  guess  that  it  is  2.5. 

b)  to  break  out  the  data  packet  "success"  percentages  by 
link  rather  than  having  to  deal  with  a  composite 
overall  "success"  percentage.  Actually,  the  composite 
number  may  be  a  useful  summary  as  long  as  the  data  on 
missed  hello  packets  is  available.  The  latter  gives 

a  more  detailed  measure  of  success  by  link. 

2.3  SUMMARY  OF  SATNET  DATA;  AUGUST,  SEPTEMBER  1979 

A  compilation  of  the  SATNET  performance  data  for 
August  and  September  1979  is  given  in  Table  2-3  through  2-6. 
Tables  2-3  and  2-4  give  data  on  missed  hello  packets  for  the 
two  months.  The  monthly  average  miss  percentage  for  all  links 
is  0.06  percent  in  August  and  0.12  percent  in  September.  The 
trends  of  missed  hello  packets  by  day  for  selected  links  is  given 
in  Figures  2-2  and  2-3  for  August  and  September,  respectively. 

SATNET  summary  data  for  August  and  September  is  given 
in  Tables  2-5  and  2-6,  respectively.  As  noted  in  Section  2.2.2, 
the  network  success  rate  often  gives  a  number  greater  than  one 
indicating  more  packets  reported  received  than  were  reported 
transmitted.  This  is  a  useful  overall  performance  measure,  but 


lj  v  w  w  i 


•  msaas» 


Table  2-5.  SATNET  Summary  Data,  August  1979 


14.4 1  13.0  j  6.0  1.3  1.4  1.4  9.2  19^  4.7  0.9  0.7  9.2  10.6  16.2  I  6.7  6.7  lu.fi  9.7 


Link,  August  1979 


IBQBQI 

taBDD 

■□E1Q 


day  by  Link,  September  1979 


»■  ^  -  . ;  -  j  —  fc  w  * 


3.  ACTIVITIES  UNDER  TASK  2  -  INTERNETTING  EXPERIMENTS 


3 . 1  PREPARATIONS  FOR  SATNET  DEMONSTRATION 


A  major  part  of  COMSAT's  activities  under  Task  2  has 
been  the  coordination  of  a  demonstration  of  SATNET  technology  to 
be  held  in  conjunction  with  a  technical  session  at  NTC-79,  to  be 
held  in  Washington  in  late  November,  1979.  The  demonstration  is 
to  highlight  the  multi-media  and  internetworking  capabilities  of 
the  system  and  is  to  involve  packet  speech,  facsimile  and  record 
traffic  of  various  kinds.  The  vehicle  for  conducting  this  demon¬ 
stration  is  to  be  a  small  computer  system,  called  the  Demo  Terminal, 
which  includes  interfaces  for  the  Lincoln  Laboratory  LPCM  vocoder 
and  Dacom  450  facsimile  scanner/printer,  together  with  a  number 
of  peripheral  devices.  The  software  for  this  system,  now  under 
development,  is  compatible  with  recent  internet  protocols  developed 
within  the  ARPANET  community,  including  TCP-4,  TELNET  and  special 
protocols  developed  for  real-time  speech. 

For  the  purposes  of  demonstrations  and  experiments,  the 
Demo  Terminal  is  to  be  connected  to  a  PDP  11  gateway  computer  now 
located  at  COMSAT  Laboratories  in  Clarksburg.  This  machine,  which 
functions  as  an  interface  to  SATNET,  is  connected  to  the  Clarks¬ 
burg  SIMP  satellite  channel  interface  computer  in  a  manner  similar 
to  other  gateways,  including  those  at  BBN  (Etam),  NDRE  (Tanum) 
and  UCL  (Goonhilly).  However,  in  the  Clarksburg  case  the  earth 
station  is  capable  of  receiving  only  at  a  16  kbit/s  rate,  rather 
than  the  64  kbit/s  rate  used  by  the  other  stations.  This  fact 
considerably  complicates  the  channel  scheduling  algorithm  used  to 
determine  which  station  transmits  at  a  particular  time,  and  the 
software  to  support  this  mixed  rate  operation  is  not  yet  completely 
developed. 
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From  the  standpoint  of  the  November  demonstration,  it 
is  highly  desirable  to  demonstrate  those  aspects  of  the  SATNET 
design  which  advance  the  state  of  the  art  vis-a-vis  current  systems 
Probably  the  most  important  of  these  is  the  integration  of  real¬ 
time  speech,  which  must  be  delivered  subject  to  critical  delay 
limitations,  and  record  data,  which  can  be  delayed  in  the  interest 
of  efficient  channel  utilization.  The  equipment  now  in  place  at 
the  various  experiment  sites  provides  the  capability  to  support 
real-time  speech  and  record  data  between  domestic  U.S.  gateways 
and  UCL  (London)  and  between  these  sites  and  the  U.S.  and  European 
ARPANET.  It  would  be  highly  desirable  to  demonstrate  facsimile 
transmission  via  SATNET,  and  work  is  now  proceeding  on  implementing 
appropriate  interface  software.  While  it  is  probable  that  the 
demonstration  could  take  place  even  without  the  facsimile  cap¬ 
ability,  real-time  speech  is  considered  to  be  necessary  for  a 
meaningful  demonstration  and  hence  will  be  given  priority. 

An  additional  important  goal  for  the  demonstration  is  to  be 
able  to  demonstrate  full  SATNET  connectivity  via  the  Clarksburg 
gateway  and  the  UET;  however,  the  present  software  can  support 
this  only  in  a  marginal  way.  This  is  because  of  two  factors. 

The  first  is  that  a  special  temporary  connection  has  had  to  be 
made  via  SATNET  to  support  older  protocols  until  use  of  these 
protocols  can  be  phased  out.  The  second  is  that  control  informa¬ 
tion  coordinating  the  channel  scheduling  process  is  now  sent  at 
the  rate  of  the  lowest-rate  earth  station  in  the  net,  16  kbit/s 
when  Clarksburg  is  active.  Accordingly,  at  least  for  the  demon¬ 
stration,  Clarksburg  cannot  be  used  on  the  operational  SATNET 
channel,  at  least  for  speech. 

To  provide  an  effective  demonstration  including  real-time 
speech,  a  connection  to  a  gateway  other  than  Clarksburg  is  required 
This  can  be  done  in  two  ways,  as  shown  in  Figure  3-1.  The  only 
domestic  U.S.  earth  station,  other  than  Clarksburg,  connected  to 
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Possible  Demonstration  Configuration 


SATNET  is  Etam.  Normally  it  is  connected  via  a  line  to  the  BBN 
gateway  in  Boston  and  by  another  line  to  the  SDAC  Pluribus-IMP  in 
Arlington.  The  SDAC  connection  is  operated  on  an  IMP- IMP  basis 
in  order  to  support  the  European  direct-connection  mentioned  above 
and  on  a  Host-IMP  (VDH)  basis  in  order  to  perform  certain  tasks 
related  to  maintenance  and  development.  The  BBN  connection  is 
operated  on  a  Host-IMP  basis  for  SATNET  traffic  only.  As  a  pos¬ 
sible  solution  for  Demo  Terminal  access  to  SATNET,  a  line  could 
be  run  from  Clarksburg  the  COMSAT  gateway  to  Etam  and  used  instead 
of  the  Etam-Boston  line  during  the  demonstration.  The  COMSAT 
gateway  would  then  temporarily  replace  the  BBN  gateway.  Connec¬ 
tivity  via  the  Clarksburg  SIMP  could  be  restored  by  manually 
switching  or  replugging  the  lines  as  required.  However,  recon¬ 
figuration  on- the- fly  in  this  manner  has  previously  been  a  source 
of  considerable  trouble  and,  in  any  case,  requires  complex  and 
time-consuming  software  reconfiguration  as  well. 

The  second  option,  which  is  by  far  the  most  attractive, 
is  to  run  a  line  from  the  demonstration  site  to  the  BBN  gateway. 
This  configuration,  shown  in  Figure  3-2,  provides  full  access  to 
SATNET  via  either  Etam,  Clarksburg  or  both.  A  problem  with  this 
connection,  however,  is  that  connection  to  the  domestic  ARPANET 
is  possible  only  via  a  second  satellite  hop  via  Norway,  which 
introduces  additional  delay  for  this  traffic.  Nevertheless,  this 
connection  provides  the  most  reliable  scenario,  as  well  as  allowing 
direct  comparisons  between  Etam  and  Clarksburg. 

Although  the  Demo  Terminal  will  support  point-to-point  speech, 
it  does  not  yet  support  conference  speech,  where  several  users 
can  share  the  common  satellite  channel  in  a  controlled,  dynamic 
fashion.  Software  to  support  this  mode  has  been  implemented  by 
Lincoln  Laboratories  but  runs  only  in  the  PDP  11  gateway  machines. 
The  operational  and  logistic  factors  to  support  a  demonstration 
of  conference  speech  would  seem  so  extreme  as  to  preclude  its 


Figure  3-2.  Alternative  Configuration 


possibility;  however,  a  movie  is  now  being  prepared  which  shows  a 
live  conference  in  progress,  and  it  may  be  almost  as  effective  to 
show  this  instead. 

There  is  an  issue  regarding  connectivity  between  the  Demo 
Terminal  and  gateways.  With  the  present  configuration,  a  pair  of 
Error  Control  Units  (ECU)  are  required  for  connection  to  each 
gateway.  DARPA  has  agreed  to  provide  a  pair  of  these  for  con¬ 
nection  between  the  COMSAT  gateway  and  Demo  Terminal;  however,  a 
second  pair  will  be  required  for  connection  to  the  BBN  gateway. 
Since  the  latter  pair  will  be  necessary  only  for  a  short  time 
bracketing  the  demonstration,  efforts  will  be  made  to  borrow 
these  units  from  another  site. 

In  summary,  the  following  seems  an  appropriate  plan  to 
implement  the  November  demonstration: 

a.  Order  a  4.8  kbit/s  digital  line  from  the  convention 
site  to  Clarksburg  and  Boston.  These  would  be  installed  approxi¬ 
mately  a  month  before  the  demonstration  and  removed  shortly  after. 

b.  Borrow  an  additional  pair  of  ECU's  from  elsewhere  in 

the  ARPANET  community  for  about  a  month,  coinciding  with  the  above. 

c.  Lease  a  Dacom  450  facsimile  terminal  for  a  period  of 
about  three  months.  This  would  allow  time  to  develop  the  hard¬ 
ware  and  software  interfaces  between  it  and  the  Demo  Terminal  and, 
finally,  to  demonstrate  the  capability  for  transmission  between 
it  and  UCL  (which  also  has  compatible  equipment  and  can  run  the 
same  software)  and  for  archiving,  etc.,  with  ARPANET  hosts. 

d.  Plan  on  moving  the  Demo  Terminal  and  the  Dacom  450  to 
the  convention  site  a  few  days  before  the  demonstration  for  last 
minute  checkout. 

The  overall  configuration  planned  for  the  November 
demonstration  is  shown  in  Figure  3-3. 


3-6 


INTERNETTING  ISSUES 


3.2.1  USE  OF  TCP  AND  RTP  IN  THE  DEMO  TERMINAL 

Several  issues  are  explored  concerning  operation  of 
internet  protocol  modules  in  the  Demo  Terminal  which  runs  DCN 
software.  These  protocol  modules  are  designed  to  support  inter¬ 
net  connections  with  hosts  on  other  networks,  including  SATNET, 
PRNET  and  ARPANET  for  real-time  (speech)  and  record  traffic. 

The  DCN  supports  user  processes  which  can  run  the  RT-11 
system  and  user  programs.  Insofar  as  practical,  the  internet 
interfaces  to  these  processes  have  been  cast  in  a  manner  com¬ 
patible  with  the  RT-11  programming  conventions,  so  that  appli¬ 
cation  programs  can  be  constructed  in  high-level  languages  such 
as  FORTRAN.  The  implementation  described  here  supports  multiple- 
connection  user  and  server  access  to  TCP,  as  well  as  raw  internet 
datagram  access  for  real-time  speech. 


3.2.2  ARCHITECTURE  OVERVIEW 

The  basis  for  much  of  the  implementation  is  the  TCP4 
and  TELNET  modules  for  SRI.  These  have  been  modified  for  use  in 
the  Basic  Operating  System  (BOS),  which  supports  the  DCN  in  LSI-11 
machines.  In  general,  the  modifications  required  have  been  minor 
and  preserve  the  general  philosophy  and  integrity  of  the  original 
design.  The  general  organization,  shown  in  Figure  3-4,  includes 
a  single  process  as  the  internet  attachment  for  a  number  of  con¬ 
nections,  all  of  which  must  be  in  the  same  machine  (called  a  hostel) 
as  this  process.  A  gateway  process,  which  can  be  in  a  different 
hostel,  interfaces  the  internet  process  to  the  outside  world  (that 
is,  outside  the  collection  of  hostels  which  represent  the  DCN) 
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(TCB  POINTER) 


Figure  3-4.  System  Architecture 


via  a  network-specific  driver.  In  the  COMSAT  case  this  driver 
connects  to  the  COMSAT  gateway  via  an  1822  link  and  is  compatible 
with  the  Port  Expanders. 

Interface  to  user  processes  is  via  a  set  of  routines 
which  operate  as  part  of  the  RT-11  emulator  package  for  the  BOS. 

A  number  of  programmed  requests  (EMT's)  are  provided  to  perform 
the  TCP4  functions  of  $OPEN,  $CLOSE,  $SEND,  $RECV  and  $INT  (the 
last  is  not  implemented  yet). 

The  internet  process,  user  processes  and  gateway  process 
communicate  with  each  other  using  short  messages  similar  in  function 
to  the  $SGNLI  primitives  of  MOS.  Where  necessary,  these  point  to 
packet  buffers  allocated  from  a  common  pool  shared  by  all  processes 
in  the  hostel. 

In  the  original  TCP4  design  the  network  drivers  were 
closely  coupled  to  the  TCP  process  itself.  In  the  DCN  design  the 
gateway  process  (and  possibly  the  user  process)  may  be  required 
to  reside  in  different  hostels.  For  this  reason  the  TCP4  packet- 
allocation  strategy  was  changed  so  that  packets  are  always  allocated 
by  the  process  that  fills  them  and  deallocated  by  the  process  that 
empties  them.  In  the  case  of  packets  exchanged  between  hostels, 
for  example,  the  gateway  process  allocates  a  packet  buffer  for  a 
packet  received  from  the  COMSAT  gateway  and  passes  it  to  the  inter¬ 
nal  device  driver  for  transmission  to  the  hostel  containing  the 
internet  process.  Once  transmitted  (and  ACKed  if  required)  the 
packet  buffer  is  de-allocated.  The  internal  device  driver  in  the 
internet  hostel  allocates  its  own  packet  buffer  and  passes  it  to 
the  internet  process,  which  consumes  its  contents  and  then  deal¬ 
locates  it.  Flow  control  is  maintained  by  end-to-end  acknowledge¬ 
ments  (in  this  case  from  the  internet  process  to  the  gateway  process 
via  the  internal  drivers)  which  take  a  form  similar  to  the  $SGNLI 
messages  mentioned  above.  These  mechanisms  require  no  packet  buffers 
and  are  buffered  separately. 
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3.2.3 


INTEk'  T  CONNECTIONS 


Each  internet  connection  supported  by  a  single  internet 
process  is  described  by  a  control  block  called  the  TCB.  At  present 
there  are  two  protocol  modules  that  can  run  in  such  a  process  — 

TCP4  and  RTP .  The  choice  of  which  of  these  modules  to  use  for  a 
particular  connection  is  determined  by  a  protocol  field  in  the 
TCB  and  by  the  protocol  field  in  the  internet  header.  The  user 
interface  to  each  of  these  is  the  same,  with  the  exception  that 
the  full  complement  of  connection-related  signals  (open/close 
complete,  etc.)  is  available  only  with  TCP.  Date  exchanged  via 
TCP  is,  of  course,  guaranteed  reliable  and  in  sequence,  while 
date  exchanged  via  RTP  consist  of  raw  internet  datagram  packets. 
Present  plans  call  for  implementation  of  certain  internet  options 
necessary  for  SATNET  stream  access  only  in  RTP,  although  they  may 
be  incorporated  into  TCP  in  the  future. 

The  present  design  can  support  a  number  of  internet  processes 
and  protocol  modules  in  the  same  or  different  hostels,  but  it  is 
not  necessary  that  each  hostel  has  every  module.  In  these  cases 
data  are  exchanged  using  the  existing  DCN  protocols,  which  assume 
reliable,  sequenced  delivery  using  the  same  message  system  used 
to  transport  packets  and  $SGNLI  messages.  A  practical  scenario 
might  include  an  internet  process  and  RTP  protocol  module  in  one 
hostel,  a  speech  module  in  another  and  a  control  program  in  a 
third,  with  operator  terminal  and  gateway  access  in  any  of  these 
or  in  a  separate  hostel.  Present  plans  call  for  all  of  these 
functions  in  a  single  30K-word  hostel  which  provides,  for  example, 
about  8K  words  for  a  speech  application  program  and  4K  words  for 
a  TELNET  user/server. 

A  particularly  crucial  issue  is  where  to  put  the  largish 
TCB,  currently  about  2000  (decimal)  words.  In  a  multiple-connection 
application  such  as  FTP  these  TCB's,  together  with  packet  buffers, 


can  consume  a  large  fraction  of  the  available  hostel  storage.  A 
frequent  problem  with  MOS  and  ELF  implementations  has  been  exhaustion 
of  what  can  loosely  be  called  supervisor  storage,  or  storage  that 
is  not  mapped  in  the  virtual  sense.  In  the  BOS  implementation 
TCB's  are  in  user  space,  so  that  potentially  a  moderately  large 
number  of  connections  can  be  sustained  without  straining  supervisor 
storage,  which  is  then  available  for  packet  buffers  and  other 
storage  structures  required  to  be  "wired  down"  for  DMA  data  transfers 
This  philosophy  requires  the  internet  protocol  modules  to  perform 
a  virtual-windowing  operation  to  map  the  TCB  into  the  address  space 
of  the  supporting  internet  process.  In  the  structure  shown  in 
Figure  3-4  the  internet  protocol  modules  are  implemented  as  sub¬ 
routines  using  register  R5  as  a  base  register.  It  is  a  simple 
matter  to  extend  this  base  by  means  of  a  reserved  segment  in  the 
kernel-space  memory-management  hardware,  so  long  as  the  TCB  itself 
is  wired  down  and  not  swapped  to  secondary  storage.  Extensions 
to  the  implementation  to  provide  these  features  would  be  simple 
and  possible  with  PDP11/40  or  LSI-11/23  hardware. 

3.2.4  MULTIPLEXING  BEYOND  THE  TCP/RTP 

The  internet  address  uniquely  specifies  an  internet 
process  in  the  DCN,  while  the  protocol  field  specifies  whether 
TCP4  or  RTP  protocol  module  is  selected.  It  is  natural  and  inviting 
to  interpret  the  16-bit  port  field  in  the  internet  header  as  the 
DCN  port  address  of  the  user  process.  Unfortunately,  such  an  inter¬ 
pretation  does  not  provide  for  multiple  connections  to  a  single 
process  and  does  not  match  with  the  interpretation  used  by  the 
Terminal  Interface  Unit  (TIU)  software.  In  the  present  implementa¬ 
tion  the  port  field  is  left  uninterpreted  and  is  established  by 
the  user  process  in  an  $OPEN  operation.  An  incoming  message  re¬ 
ceived  by  the  internet  process  is  associated  with  the  proper 


connection  by  simply  searching  and  matching  the  corresponding  port 
fields  in  the  message  and  the  TCB .  The  only  requirement  is  that 
this  association  is  unambiguous. 

In  the  TIU  software  the  internet  address  itself  is  used 
to  provide  this  multiplexing  function,  since  the  port  field  is 
conventionally  used  within  the  ARPANET  to  establish  the  type  of 
server  (TELNET,  FTP,  etc.)  requested.  This  hack  would  cause  much 
grief  in  the  DCN  and  is  replaced  by  the  mechanism  described  above. 
Further  discussion  is  advisable  on  this  point. 

By  convention,  port  23  on  the  TCP  for  every  internet 
process  is  reserved  for  an  RT-11  server  process  compatible  with 
TELNET.  The  TCB  for  this  server  is  allocated  "out  of  band"  in  an 
area  normally  used  by  device  drivers  in  RT-11.  Additional  TCB's 
for  other  connections  can  be  allocated  elsewhere  in  this  and  other 
user  processes.  Also  by  convention,  port  1  is  reserved  for  a 
TELNET  user  process,  which  runs  SRI  TELNET  virtually  unchanged. 
Internet  echo  and  sink  processes  are  included  in  the  system  for 
testing.  Internet  datagrams  from  TCP  or  RTP  are  simply  returned 
to  the  sender  with  local  and  foreign  address  fields  interchanged. 

3.2.5  OTHER  ISSUES 

At  present  there  is  no  support  for  the  urgent  or  interrupt 
mechanism  in  either  TCP  or  TELNET.  Facilities  already  exist  in 
DCN  to  propagate  these  functions  beyond  the  TCP,  and  they  will  be 
required  in  any  real  application.  TELNET  itself  is  largely  super¬ 
fluous  in  the  system  and  its  functions  can  be  provided  by  using 
existing  DCN  mechanisms  augmented  by  suitable  TELNET  option- 
negotiation  mechanisms. 

A  provision  for  file  transfer  between  DCN  hosts  separated 
by  SATNET  is  urgently  needed,  as  well  as  a  provision  for  file 


transfer  between  these  hosts  and  an  ARPANET  host.  Using  the 
facilities  currently  implemented  (namely  multi-connection  TELNET) 
it  is  possible  to  implement  a  minimal  version  of  ARPANET  FTP.  A 
workable,  if  unatractive,  interim  file-transfer  mechanism  might 
be  to  use  the  present  DCN  file-transfer  package,  designed  to  work 
through  a  TIP,  on  a  TELNET  connection  to  an  ARPANET  host. 


4.  ACTIVITIES  UNDER  TASK  3:  WIDEBAND  INTEGRATION/COORDINATION 


4.1  INTRODUCTION 


COMSAT's  participation  in  the  wideband  domestic  network 
planning  (also  referred  to  as  EISN,  for  Experimental  Integrated 
Switched  Network)  has  concentrated  on  a  review  of  communications 
link  performance  predictions  and  simulations  of  several  candidate 
frequency  plans.  Information  collection  began  in  April  of  this 
year  when  the  implementing  organizations  (Western  Union  and  Linkabit) 
provided  information  relative  to  communication  link  characteristics 
and  modem  design  parameters.  This  information  was  incorporated 
into  a  simulation  of  overall  link  performance.  This  detailed  infor¬ 
mation  was  summarized  in  the  First  Quarterly  Report. 

In  this  report,  EISN  link  budgets  are  reviewed  in  the 
next  subsection.  Simulation  results  are  presented  in  the  next 
two  subsections  for  candidate  frequency  plans  that  are  the  most 
likely  final  configurations  of  the  WESTAR  transponder  that  will 
contain  the  EISN  QPSK  carrier. 
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REVIEW  OF  LINK  BUDGETS 


The  link  budgets  for  the  up-link  of  the  wideband  channel 
are  summarized  in  Table  4-1.  Up-link  C/N  is  obtained  as: 
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is  the  up-link  C/N  ratio  in  the  allocated 
spacecraft  bandwidth 
spacecraft  saturation  flux  density 
input  backoff  to  the  transponder 
satellite  receive  antenna  gain 
operating  wavelength  on  up-link 
up-link  rain  attenuation  margin 
Boltzmann's  constant 
satellite  receive  noise  temperature 
allocated  bandwidth. 


The  HPA  requirement  (pHpA)  to  produce  the  correct  carrier  level 
at  the  satellite  can  be  obtained  from: 


PHPA  *  GESLT 
4nR2 
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where 


P  = 
HPA 


R  = 


required  power  from  HPA 

earth  station  antenna  gain 

line  loss  HPA  to  antenna 

distance  from  earth  station  to  satellite. 


The  required  earth  station  HPA  capability  is  tabulated  in  Table  4-2 
The  down-link  C/N  levels  can  be  obtained  from  the 
relationship 
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Table  4-2.  Required  HPA  Capability 


Reston  Lexington 

Menlo 

Park 

Marina 

Del-Rey 

Remarks 

Saturation  Flux  Density 

*  ( dBW/m2 ) 

s 

-82.0 

-82.8 

-82.3 

-81.2 

Satellite  TWTA  Input 
Backoff  (dB) 

-21.0 

-21.0 

-21.0 

-21.0 

Beam  Spreading  Loss 
(4nR2 )  (dB) 

162.5 

162.7 

162.5 

162.4 

Transmit  Antenna 

Gain  (dB) 

-47.9 

-47.9 

-47.9 

-47.9 

Line  Loss  (dB) 

0.9 

0.9 

0.9 

0.9 

From  HPA  to 

Power  required  from 

HPA  (dBW) 

+12.5 

TT79 

12.2 

13.2 

antenna  feeds 

Maximum  HPA  power 
available 

18.75 

18.75 

18.75 

18.75 

75  W  tube 

Margin  for  HPA  backoff, 
clear  sky  (dB) 

6.3 

6.9 

6.6 

5.6 

where  the  terms  not  previously  defined  are 

e.i.r.p.g  =  saturated  e.i.r.p.  of  satellite 
boQ  =  output  backoff  of  QPSK  carrier 
Mjj  =  down-link  loss  due  to  rain 
=  down-link  operating  wavelength 
GES  =  9a^n  °f  earth  station 

TES  =  effective  noise  temperature  of  earth  station 
The  down-link  relationships  are  tabulated  in  Table  4-3. 
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Table  4-3.  Down-Link  Relationship* 
and  Overall  Per'.ormance 


Reaton 

Lexington 

Menlo 

Park 

Marina 
Do  1-Rey 

Remark* 

e.i.r.p.  at  saturation 
(dOW) 

35.0 

33.9 

U.3 

33.9 

QPSK-carrier 

Output  backoff  (dB) 

-16.0 

-16.0 

-16.0 

-16.0 

Path-Loss  (dB) 

-195.7 

-195. 8 

-195.7 

-195.7 

Rain  Margin  (dB) 

-0.1 

-0.1 

-0.1 

-0.1 

G/T  (dB/K) 

22.0 

22.0 

22.0 

22.  0 

Bandwidth  (dB-H2) 

-63.0 

-63.0 

-63.0 

-63.0 

B#  »  2  MHz 

— 

k(dBW/Hz/K) 

228.6 

228.  6 

228.6 

228.6 

(C/N)dn  (dB) 

10.8 

9.6 

10.1 

9.7 

(C/N)op  (dB) 

18.2 

18.2 

18.2 

18.2 

From  Table  4-1 

Total  Interference 
Allocation  C/I  (dB) 

19.0 

19.0 

19.0 

19.0 

(Assumption) 

’ 

Total  Available 

Overall  <C/N)T 

9.6 

8.6 

9.0 

8.7 

C/N  in  2  MHz  BN 

Overall  Available 

C/Nq  (dB-Hz) 

72.6 

71.6 

72.0 

7. .7 

;;  \ 

Eb/N0  Required  for 

5  x  10  5  Raw  Channel 

Error  Kate  <dB) 

5.  3 

5.  3 

5.  3 

5.3 

Theoretical 

'  -4 

Modem  Implementation 

Loss  (du) 

1.5 

1.5 

1.5 

1.5 

Assumed 

•A 

Conversion  from  E^/Ng 
to  Es/Nq  (dB) 

3.0 

3.  0 

3.0 

3.0 

E  1  Encr-ji^^rgPSK  Symbol 

so  Noise  Density 

**  *1 

-.'1 

Bandwidth  Correction 
(1.544  x  10‘/2  x  10‘) (dB) 

-1.1 

-1.1 

-1.1 

-1.1 

C/N  above  computed  in  2  MH* 

Bandwidth 

-  l 

- 1 

Required  "C/N*  in  2  MHz 
Bandwidth  (dB) 

8.7 

8.7 

6.7 

8.7 

:  j 

•  j 
' 

1 

\  1 
■  ‘i 

Marginal  Overall  (dB) 

+0.  9 

-0.1 

+0.  3 

0 

Comparing  (C/N)_  availabia 
to  Required 

-J 


In  the  lower  part  of  the  table,  overall  C/N  is  obtained, 
(C/N)t.  This  value  is  compared  to  the  C/N  required  to  guarantee 
a  "raw”  channel  error  rate  of  5  x  10“3.  This  raw  channel  error 
rate  would,  of  course,  be  improved  by  any  error  control  coding 
used  on  portions  of  the  transmitted  packets.  These  results  apply 
to  QPSK  transmission  at  a  symbol  rate  of  1.544  x  106  symbols/second 
and  an  information  bit  rate  of  3.088  Mbit/s. 


4.3  EVALUATION  OF  CANDIDATE  FREQUENCY  PLANS 


4.3.1  INTRODUCTION 

Several  candidate  frequency  plans  have  been  evaluated 
by  computer  simulation  to  determine  overall  losses  to  be  expected 
for  the  1.544  M  symbol/second  E1SN  carrier.  These  plans  were  re¬ 
covered  from  Western  Union  at  two  different  meetings.  The  cases 
examined  can  be  summarized  as  follows: 

a.  At  a  meeting  held  with  Western  Union  (McLean,  Virginia) 
on  27  April  1979,  a  frequency  plan  was  obtained  where  the  EISN 
carrier  would  share  the  WESTAR  transponder  with  a  single  660-channel 
FDM/FM  carrier. 

b.  On  9  July,  another  meeting  was  held  at  Western  Union 
(Upper  Saddle  River,  New  Jersey)  where  three  additional  candidate 
frequency  plans  were  obtained.  One  of  these  involved  the  exclusive 
use  of  the  transponder  by  the  EISN  carrier.  The  second,  referred 
to  as  the  "hybrid  transponder"  plan,  was  the  most  likely  final 
configuration,  and  emphasis  was  focused  on  investigating  this  plan. 

A  third  possible  plan  called  for  the  EISN  carrier  to  share  a  trans¬ 
ponder  with  six  T-l  carriers.  To  date,  this  third  additional  plan 
has  not  been  simulated. 
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Preliminary  simulation  results  for  the  two  plans  simulated  to  date 
are  given  in  the  next  two  sections.  The  detailed  simulation  model 
and  most  of  the  element  characteristics  were  described  in  the  First 
Quarterly  Progress  Report.* 


4.3.2  SIMULATION  RESULTS  FOR  ORIGINAL  TWO  CARRIER  FREQUENCY 
PLAN 


The  examination  of  the  original  EISN  frequency  plan 
addresses  the  case  where  the  EISN  carrier  shares  the  transponder 
with  one  other  relatively  wideband  FM  carrier. 

For  the  computer  simulations,  the  36  MHz  transponder  is 
assumed  to  be  accessed  by  the  1 . 544  M  symbol/second  QPSK  ARPA  carrier 
and  by  a  660-channel  FDM/FM  carrier.  The  general  frequency  plan 
is  shown  in  Figure  4-1.  Baseline  modem  back-to-back  simulations 
were  made  giving  the  eye  diagram  and  scatter  diagram  shown  in 
Figure  4-2a  and  b,  respectively.  Simulated  modem  performance  with 
ideal  synchronization  is  shown  in  Figure  4-3. 

From  the  simulation  results,  the  maximum  (worst  case) 
out-of-band  emission  levels  can  be  predicted  using  the  simulated 
spectra  in  Figure  4-4.  This  spectral  density  applies  to  the  case 
where  the  earth  station  HPA  is  operated  with  no  output  backoff. 

An  estimate  of  the  reduction  in  out-of-band  emission  levels,  as 
the  earth  station  HPA  is  backed  off,  is  given  in  Figure  4-5.  Note, 
for  example,  that  operation  with  6  to  7  dB  output  backoff  (see 
Table  4-2)  would  reduce  the  out-of-band  emission  levels  by  approx¬ 
imately  5  dB. 

*"First  Quarterly  Progress  Report,"  under  Contract  MDA-903-79-C-0308, 
by  COMSAT  Labs,  dated  December  1979. 
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Figure  4-1.  Original  Frequency  Plan  for  the  Westar  Satellite 
Transponder  Carrying  the  1.544  Mbaud  QPSK  ARPA  Carrier 


EYE  PATTERN  -  UNIT  4 


BAUD  RATE  =  1.544  TO,  PHZO  =  24.54,  -0.00 

SAMPLE  RATE  *  24.704 


Figure  4-4.  Maximum  QPSK  Cut-of-Band  Emission  at  HPA  Output 

(HPA  Saturated) 


ESTIMATED 
REDUCTION 
OF  QPSK 
OUT-OF-BAND 
EMISSION 
(dB) 


15 


20 


25  l—i 
25 


20  15  10  5 


HPA  SINGLE-CARRIER  INPUT  BACKOFF  :  B 


Figure  4-5.  Assumed  Relation  of  Relative  Out-of-Band 
Emission  to  HPA  Input  Backoff 


1.  1.1 
:(dB) 
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The  analysis  results  in  Figure  4-6  give  intermodulation 
distortion  (IM)  levels  falling  into  the  ARPA  QPSK  carrier.  These 
IM  levels  are  caused  by  common  amplification  by  the  satellite  TWTA 
of  the  QPSK  and  FM  carriers.  This  same  figure  gives  estimates  of 
the  levels  of  intermodulation  distortion  falling  into  the  660-channel 
FDM/FM  carrier. 

Adjacent  transponder  interference  levels  caused  by  IM 
distortion  are  shown  in  Figure  4-6,  and  all  interference  levels 
are  summarized  in  Table  4-4. 

Table  4-4  -  Interference  Levels  into  ARPA  QPSK  Carrier 

Remarks 


( Intermodulation 

No  Appreciable  IM 

Distortion  (IM)) 

Expected 

c/IATrI • 

(Out-of-Band  Emission 

27.0 

dB 

Same  as  previous 

from  Adjacent  Trans¬ 
ponders  ) 

estimates 

V'exf 

(Adjacent  Satellite 

26.0 

dB 

Same  as  previous 

Interference) 

estimates 

VW- 

(Terrestrial  System 

26.0 

dB 

Same  as  previous 

Interference) 

estimates 

Total  C/I 

Estimate 

21.5 

dB 

(Previous  estimate 
of  19 . OdB) 

Note:  The  slightly  higher  (better)  C/I  estimate  will  not  significantly 
affect  previous  link  margin  estimates. 

Relative  Out-of-band  emission  (OBE)  levels  caused  on  the  up-path 
by  the  OPSK  carrier  (due  to  spectrum  spreading  caused  by  the 
nonlinear  HPA  characteristics)  are  summarized  in  Table  4-5. 


Figure  4-6.  Estimated  Intermodulation  Distortion  Spectrum  at  Satellite 

TWTA  Output 


Table  4-5.  Interference  Caused  by  the  ARPA  Carrier  into  the 
FM  Carrier  in  the  Same  Transponder  and  into 
Carriers  in  Adjacent  Transponders 


Remarks 


Maximum  QPSK  OBE 
( dBW/4  kHz) 

~8 . 1 

±2  MHz  from  QPSK 
carrier  center  frequency 

OBE  into  FM  carrier 

negligible 

About  19  MHz  separation 

OBE  into  adjacent 
transponder  ( dBW/4  kHz ) 

<  -2 

Near  band-edge 

IM  distortion  (C/I) 
into  FM  carrier  (dB) 

50  dB 

IM  distortion  power 
density  into  adjacent 
transponder  (dBW/4  kHz) 

-39.5 

Near  band-edge 

Note:  These  results  show 
to  be  negligible. 

that  interference  effects  are  expected 

For  the  original 

two-carrier 

frequency  plan,  the  level 

of  IM  distortion  falling  into  the  FM  carrier  and  into  the  adjacent 
transponders  is  concluded  to  be  negligible.  The  level  of  out-of- 
band  emission  caused  by  the  QPSK  carrier  on  the  up-path  to  the 
satellite  is  also  negligible.  The  above  conclusions  should  be 
reexamined  for  other  frequency  plans. 

Estimates  of  overall  in-band  transmission  impairments 
experienced  by  the  QPSK  carrier  over  the  transmission  path  are 
given  in  Figure  4-7.  This  figure  shows  the  increase  of  carrier-to- 
noise  ratio  required  for  a  bit  error  rate  (BER)  of  5  x  10~3  above 
theoretical  ideal  value.  This  estimate  is  obtained  via  a  simplified 
computer  simulation  where  modem  synchronization  circuits  are  assumed 
to  be  hard-wired.  The  satellite  transponder  filters  and  the  FDM/FM 
carrier  were  not  included  in  this  particular  simulation. 


LEGEND  : 

1.  ARPA  CARRIER 

2.  THEORETICAL 

•  BER  OBJECTIVE  :  5  x  JO'3 

•  QPSK  (1.544  MBAND) 

•  NO  DIFFERENTIAL  ENCODING 

•  REFERENCE  BANDWIDTH  =2  MHi 

•  SYNCHRONIZATION  CIRCUITS  :  HARD-WI  j 
S,  •  HPA  INPUT  BACKOFF  :  10  dB 

\  •  SATE  LITE  TWTA  INPUT  BACKOFF  :  9.6  dB ' 

\  •  SATELITE  FILTERS  NOT  INCLUDED 


NOTE  :  - 

AT  A  BER  OF  5  x  10‘3  THE  ; 

TRANSMISSION  IMPAIRMENT  WITHOUT  - 
SYNCHRONIZATION  CIRCUIT  LOSSES  I 
UND  WITHOUT  ANY  LOSS  DUE  TO 
\SATELITE  FILTERS  IS  ABOUT  0.4  dB 
\FROM  THEORETICAL 


^CONSEQUENTLY  THE  ESTIMATED 
\  LOSS  OF  1.5  dB  FOR  ALL  THESE 
\LOSSES  INCLUDED  MAY  BE 
\ADEQUATE 


5.9  6.9  7.9  8.9  9.9  10.9  11.9  12.9  13.9  14.9  15.9  16.9  17.9  18.9 

RECEIVED 

CARRIER-TO-NOISE  INTERFERENCE  RATIO  C/(N*1)dB 
Figure  4-7.  Bit-Error  Rate  versus  Received  C/N  Ratio 
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The  link  budgets  and  margins  are  summarized  in  Table  4-6. 
The  link  margins  obtained  are  slightly  larger  (by  0.3  dB)  than 
the  estimates  in  Table  4-3.  This  difference  is  caused  by  the  fact 
that  IM  distortion  levels  falling  into  the  QPSK  carrier  have  been 
found  to  be  negligible  for  the  original  two-carrier  frequency  plan. 
This  accounts  for  the  fact  that  the  total  C/I  allocation  for  inter¬ 
ference  effects  is  slightly  better  than  previous  estimates  (C/I 
of  21.5  dB  instead  of  19  dB).  The  IM  levels  would  be  different 
for  other  frequency  plans. 

It  presently  appears  that  the  assumed  transmission  im¬ 
pairment  allowance  of  1.5  dB  (for  modem  implementation,  etc.)  may 
be  adequate.  This  is  based  on  the  estimated  transmission  impair¬ 
ment  of  0.4  dB  (Figure  4-7)  obtained  for  the  case  where  synchroni¬ 
zation  circuits  are  hard-wired  and  where  the  impact  of  the  trans¬ 
ponder  filters  is  omitted.  When  these  effects  are  included  the 
total  impairment  would  probably  not  exceed  1.5  dB.  Any  additional 
loss  due  to  the  satellite  filters  group  delay  distortion  could  be 
determined  through  the  more  complete  computer  simulation.  If  losses 
become  excessive,  the  QPSK  carrier  could  be  shifted  towards  the 
transponder  band-center  where  the  group  delay  distortion  is  less 
pronounced.  The  additional  loss  due  to  synchronization  circuits 
should  be  evaluated  in  future  simulation  efforts. 

It  appears  that  the  transmitted  e.i.r.p.  should  probably 
be  increased  to  improve  the  link  margins.  Since  a  75-W  HPA  will 
be  used,  there  is  sufficient  available  e.i.r.p.  at  each  earth  station 
to  achieve  this  end.  However,  the  level  of  off-axis  radiation 
(adjacent  satellite  interference)  must  be  examined  before  this 
can  be  recommended. 


4.3.3 


COMPUTER  SIMULATION  OF  THE  "HYBRID  TRANSPONDER"  FREQUENCY 
PLAN 


Preliminary  digital  computer  simulations  have  been  per¬ 
formed  of  the  17-carrier  "Hybrid"  Westar  transponder  frequency 
plan  utilizing  the  CHAMP2  computer  program.  Table  4-7  summarizes 
the  characteristics  of  each  signal. 

The  FM  signals  in  the  transponder  are  all  tone  modulated 
and  were  simulated  as  such.  All  of  the  32  kbit/s  BPSK  signals 
were  simulated  as  sinusoids  at  their  appropriate  center  frequencies. 
The  eight  QPSK  signals  were  generated  individually  with  the  parameter 
values  as  shown  in  Table  4-7. 

The  EISN  (Experimental  Integrated  Switched  Network)  signal 
was  generated  using  the  "short-pulse"  technique.  In  this  scheme, 
the  modulating  pulse  driving  the  modulator  prefilter  exists  for 
25  percent  of  the  symbol  duration.  Since  the  symbol  rate,  Rg,  is 
1.544  MSPS,  the  symbol  duration  is  648  ns.  One-quarter  of  a  symbol 
is,  therefore,  162  ns.  This  signal  was  then  passed  through  an 
equalized  7-Pole  Butterworth  filter  having  a  BT  =  1.0.  The  modu- 
lated  signal  was  then  passed  through  the  HPA  which  was  operated 
with  an  input  backoff  =  -9  dB  and  an  output  backoff  =  -4.7  dB).* 

The  other  QPSK  signals  in  the  transponder  were  generated 
utilizing  the  symbol  rates  shown  in  Table  4-7.  These  signals  were 
simulated  as  conventional  QPSK.  After  generations,  each  signal 
was  passed  through  its  own  Butterworth  filter.  At  this  point, 
all  the  signals  were  attenuated  individually  such  that  the  ratios 
of  the  power  in  each  signal  relative  to  the  EISN  signal  were  equal 
to  the  relative  levels  shown  in  Table  4-7.  All  sampled  signals 
were  then  interpolated  to  change  sampling  rate  in  order  to  make 
the  sampling  rates  for  all  signals  approximately  the  same  (within 
2  percent  of  each  other).  This  condition  of  equal  sample  rate  must 

*A11  filter  and  nonlinear  amplifier  characteristics  used  in  the 
simulation  came  from:  Devieux,  C.,  "Preliminary  Results  for  Link 
Margin  Evaluation  for  the  ARPA  1.544  Mband  QPSK  Carrier,"  COMSAT 
IOM  to  L.  Palmer,  6/29/79.  This  data  was  summarized  in  the  First 
Quarterly  Progress  Report  under  this  contract. 


4-20 


Table  4-7 .  Description  of  "Hybrid  Transponder' 
Frequency  Plan 
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exist  in  order  to  sum  all  the  signals  together  at  the  satellite 
input.  Four  distinct  QPSK  symbol  rates  were  used  and  Table  4-8 
gives  the  signal  parameters  of  interest  for  the  interpolation 
operation. 

Table  4-8.  Interpolation  Parameters  for 
Hybrid  Transponder  Simulations 

Symbol  Number  of  Samples  Intermediate  Interpolation  Final 


Rate 

Sampling  Rate 

Factor 

Samplinq  Rate 

1.544 

12 

18.53 

6 

111.17 

0.772 

12 

9.264 

12 

111.17 

0.450 

22 

9.900 

11 

108.90 

0.112 

24 

2.688 

41 

110.20 

After  interpolation  and  scaling,  all  signals  were  com¬ 
bined  and  passed  through  the  filter/TWTA/filter  combination  that 
represents  the  satellite.  The  TWTA’s  input  backoff  was  set  at 
-11.79  dB  from  saturation  (output  backoff  was  measured  as  -7.09  dB) 
Frequency  spectra  were  obtained  at  the  input  and  output  of  the 
satellite,  these  are  shown  in  Figures  4-8  and  4-9,  respectively. 
These  spectra  cover  a  band  of  approximately  three  transponder 
bandwidths,  110  MHz,  in  order  to  show  the  magnitude  of  the  adjacent 
transponder  interference  levels. 

After  the  satellite,  the  combined  signal  was  deinter- 
polated  by  a  factor  of  six  (the  interpolation  factor  used  for 
the  EISN  signal)  and  then  passed  through  the  receive  modem  filter 
which  was  an  equalized  Butterworth  filter  with  a  BTg  -  product 
equal  to  unity  and  centered  on  the  EISN  signal  center  frequency. 
Detection  and  bit-error-rate  (BER)  measurements  were  made  on 
the  EISN  signal  with  the  results,  expressed  in  the  form  of 
dB-loss  relative  to  theoretical  as  a  function  of  BER,  shown  in 
Table  4-9. 


« 


Table  4-9.  Loss  (dB  relative  to  ideal) 
Function  of  BER 


Spectral  Density  at  Output  of  Hybrid  Transponder 


